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1c: Un Ipas 


La afirmación de que las nuevas sentencias de programación de POV son la 
novedad más importante de la versión 3 de este raytracer puede parecer 
excesiva, pero dicha afirmación está siendo confirmada por las nuevas 
utilidades que están apareciendo. En el número anterior nos asombramos 
con «Trees» de Sonya Roberts y hoy volveremos a hacerlo con «Books», 


un “Ipas” de la misma autora para crear filas de libros virtuales. 


crear librerias con POV 


emos decidido de- E cillo, y podrá ser comprendido incluso ¿ correspondiente include. El número de 
nominar "Ipas” a las E por aquellos povmaníacos que sientan es- ¿ estas variables es bastante grande pero, 
nuevas utilidades de ; calofríos ante la palabra “matemáticas”. E por fortuna, no es preciso que las refe- 
POV escritas con el : a renciemos todas. De hecho Sonya ha da- 
lenguaje escénico E Filas de libros E do valores por defecto a cada una de es- 
de este Ray tracer, ¿ Books.inc permite al usuario gene- a tas variables empleando la sentencia 


ya que casi todo el mundo sube lo que es 
un Ipas (un módulo de software externo 


¿- ¡fndef. Veamos un ejemplo: 


rar filas de libros que pueden ser em- 
] Hifndef (RowLenght) ttdeclare RowLength=2 Htend 


que es llamado por 3D Studio cuandoes i-pleto:a escena 1 n esta línea, situada al principio del 
necesario y que se apoya en las prop ls | Pol s pues e este Ipas FC oks.inc, se estipula que si la 
funciones del programa). Lo: d len : y a wLenght no ha sido iniciali- 


P an CO í a ar variable V 
3D Studio emple huecafe o úmenes so as t sde el fichero escénico del 
municación con 3D Studio para acce nesas O. Los libros que gene usuario), esta pasará a tener un valor de 


cómodo para el 


í , introduc- 
diante la cual los pueden ¿ €s cenas quedarán resultonas, ya que los 

rogra - 3 volúmenes podrán tener distintos groso- 

El 5 res, colores y tamaños, y podremos va- 

O ) 3 riar su alineación dentro de las filas. 
Además, de manera similar, podremos 
hacer que las pilas de libros tengan un 
aspecto desorganizado. acorde con el 
que puede verse en las pilas de libros del 
universo real (esto 


parece ser una pre- 
ocupación cons- 


ación ¿ tante en el trabajo 
p ade: les de Sonya Roberts). 
e o sucedía 


del fo 
bros, puede no ; o espectacu ds 
lar como otro capaz de gr es. una se 
pero es un ejemplo perfecto de lo que ble 
puede conseguirse deb. 2) > ri 
ción con habilidad de programación. El 
fichero es, además. relativamente sen- 


S eteoritos, e 
erE aremos Di 
Este Ipas, que genera filas o pi 


layor variación en la colocación de la fila. 


En sl 


Variables de control 

Ahora examinemos las variables de 
control. En primer lugar tenemos a 
“Rowlenght”, que es la longitud de la 
fila o columna de libros a crear. La al- 
tura de la fila se controla con “Row- 
Height” y la profundidad de la misma 
se indica con “RowDepth”. “StackSty- 
le” indica al Ipas la forma en que van a 
colocarse los libros. Si el valor es O (el 
dado por defecto) los libros se dispon- 
drán de la manera corriente que pode- 
mos observar en cualquier estantería. 


Taller Virtual 


la pila, ésta se dispondrá de una manera 
bastante ordenada, ya que Books “só- 
lo” aplicará un desorden máximo de 20 
grados (utilizando valores aleatorios) en 
el eje Y; de esta manera se evitará el que 
los libros estén excesivamente ordena- 
dos sobre la mesa, lo que resultaría irreal. 
Finalmente podemos dar a “StackSty- 
le” el valor 2, con el cual se generará 
otra pila como la anterior, pero mucho 
más desordenada, ya que ahora el ran- 
go de giro de los libros oscila entre los 
0 y los 360 grados en el eje Y. 


Sin varlación de color y generando titulos al azar. 


Puesto que Books asume —al igual que 
la mayoria de los usuarios de POV— 
que el plano del suelo es el formado 
por los ejes X-Y, los libros se dispon- 
drán “de pie” formando una fila a lo 
largo de este plano. Los libros descan- 
sarán sobre Y=0 y sus lomos estarán 
orientados en la dirección -Z. La fila, 
que arranca en X=0. se extenderá hasta 
el punto indicado por “RowLenght”. 
Otra posibilidad es dar a “StackStyle” 
el valor 1. En este caso los libros forma- 
rán una pila como la que puede verse en 
ciertas mesas, donde el volumen que re- 
posa directamente sobre la mesa tiene 
encima una docena o más de tomos. La 
pila será colocada en la posición <0.0.0> 
y su altura dependerá del valor dado a 
“RowLenght”. En cuanto a la forma de 


Veamos ahora otras variables. “Num- 
Books” controla el número total de li- 
bros de la fila o pila. En realidad este 
número es aproximado ya que puede 
ocurrir que, a consecuencia de las va- 
riables que controlan las diferencias en 
el grosor de los libros, haya libros de 
más o de menos. En cualquier caso el 
grosor medio de los libros se calculará 
dividiendo la longitud dada a la fila en 
“RowLenght” porel valor de “NumBooks”. 
Hay que tener cuidado con los valores 
dados a estas variables u obtendremos 
unos libros ridículamente gruesos o 
muy finos, y lo mismo se aplica a las 
variables que controlan la altura de los 
tomos (“RowHeight”) o el largo de los 
mismos (“RowDepth”). Estas prapor- 
ciones no son difíciles de calcular pero 


más vale recordar que los valores de to- 
das estas variables se combinan para 
componer los resultados. 

Sigamos con otros detalles. Si todos 
los libros generados fuesen excesiva- 
mente similares en sus dimensiones, el 
resultado sería poco atractivo. Lo que 
queremos es una librería con tomos de 
diferentes tamaños, como sucede en la 
vida real. Esto se consigue con las va- 
riables “VariThick”, “VariHeight” y 
“VariDepth”, las cuales controlan res- 
pectivamente las variaciones en el gro- 
sor, la altura y el largo de los libros (con 
respecto a las dimensiones medias, por 
supuesto). Los valores dados serán de- 
cimales y es conveniente que no sean 
demasiado grandes (observe el lector el 
resultado de los valores por defecto). 

Otra variable importante de este mis- 
mo tipo es “VariAlign”. Esta se emplea 
para conseguir leves diferencias en la 
alineación de las filas de libros. El va- 
lor 0.1, asignado por defecto, nos dará 
filas muy ordenadas y valores mayores 
producirán filas más desordenadas, 

De igual manera podemos conseguir 
más diferencias entre los libros ponien- 
do a “True” la variable “VariColours”. 
Con ello se asignarán colores aleatorios 
a las cubiertas de los tomos. Si, por el 
contrario, dejamos esta variable a “fal- 
se”, los colores asignados se elegirán 
entre una gama de grises (el modo de 
color es el elegido por defecto). Aquí 
hay que decir que “true” y “false” son 
identificadores de POV. Un valor “true” 
es —como en el lenguaje C- cualquier 
valor distinto de O, mientras que “false” 
es 0. Por alguna razón Sonya empleó 
“True” en vez de “true”, con el resulta- 
do de que el parser de POV declara 
errores en algunos sitios. El autor de 
este artículo remedió esto añadiendo 


>. 


tídeclare True=true, al principio de bo- 
oks.inc (y haciendo lo mismo con fal- 
se). ¿Un error de última hora? 

Por otro lado, existe una variable 
“semilla”, llamada “BookSeed”, que se 
emplea para inicializar el generador de 
números aleatorios. Con ello podremos 
conseguir filas o pilas de libros diferen- 
tes, cambiando el valor de dicha semilla 
(si estamos generando una animación 
mantendremos el mismo valor de semi- 
lla en todos los frames para obtener 
siempre la misma fila en cada uno). 

En cuanto a “FillerColour”, controla 
el aspecto del canal del libro. Si el valor 
de esta variable es O obtendremos un 
blanco plano mientras que un valor de 
1 proporcionará tonos grises. 


Los objetos “TEXT” 

Ya sólo queda por explicar lo que ha- 
ce la variable “Titles”. Si su valor es 0, 
las cubiertas de los libros serán planas. 
Si el valor es 1, habrá títulos en inglés 
en los lomos de los libros. Realmente el 
pov-usuario no necesita saber más para 
emplear Books, pero surgen varios inte- 
rrogantes: ¿Cómo se colocan las letras 
sobre los libros? ¿Podemos poner nues- 
tros propios títulos? 

Veamos: las letras se colocan em- 
pleando los objetos Text implementa- 
dos en POV a partir de la versión 3.0, 
Antes de esta novedad cl usuario esi¡ba 
obligado a hacer operaciones CSG o a 
utilizar Heightfields para crear textos. 
Ahora, sin embargo, podemos emplear 
esta nueva primitiva para crear objetos- 
texto a partir de fuentes TrueType. El 
formato de la nueva sentencia es: 

text [ ttf “Nombre del fuente” “cadena a 


¿Amprimir” Profundidad, Separación ) 


En “Nombre del fuente” podemos es- 
pecificar alguno de los fuentes ttf que se 


.. 


han incluido como ejemplo en POV (o 
cualquier otro de que dispongamos). En 
cuanto a la cadena, normalmente usare- 
mos un string entrecomillado. También 
resulta posible emplear una variable de 
cadena, en cuyo caso bastará con incluir 
el nombre de la misma, sin las comillas. 
Los parámetros siguientes determinan la 
profundidad de la letra y el espacio de 
separación. Por defecto las letras se co- 
locan sobre el plano X-Y pudiéndose le- 
er el texto desde -Z. La parte frontal del 
texto queda en Z=0.1 y cada letra tiene 
de 0.5 a 0,75 unidades de altura. Así 
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Diferentes pruebas. Nótese como 
el título puede acabar fuera del 
libro por excesiva longitud o por 
poco grosor del libro. 


pues, “Profundidad” se refiere a las di- 
mensiones del objeto a lo largo del eje 
Z. En cuanto al siguiente parámetro 
hay que tener cuidado, ya que si no in- 
dicamos un eje, el valor de separación 
se aplicará como una suma en los tres 
ejes (cada letra se alejará de la anterior 
en cada eje). Esto se evita escribiendo 
cosas como “.3*x”, lo cual restringe 
cada desplazamiento al eje indicado. 


Cadenas 

En books los títulos se componen 
aleatoriamente definiendo un string a 
partir de la suma de otros tres. La va- 
riable string obtenida, “BookTitle”, se- 
rá luego empleada para los objetos ttx. 
Esta suma se lleva a cabo empleando 
una de las nuevas sentencias de trabajo 
con strings de la forma: 
ttdeclare BookTitle=concat(First, Second, 
Third) 

La función concat realiza la suma de 
las cadenas contenidas en las variables. 
Si por ejemplo, sus valores respectivos 
eran “The ”, “Lost” y “World”. el resul- 
tado será “The Lost World”. Las pala- 
bras para cada una de las tres variables- 
sumando se extraen aleatoriamente 
(empleando rand y switch) de tres listas 
que podemos hallar en titles.inc. (este 
método es similar al que se usaba en 
broma para hacer que los programas 
creasen poemas). Sin embargo, y por 
aquello de crear títulos en castellano, he- 
mos creado un fichero aparte donde las 
cadenas son títulos completos y no se 
emplea rand (confiemos en que Sonya 
no se moleste por ello). Hemos incluido 
ejemplos de uso. Sólo queda advertir 
que tengáis cuidado al poner vuestros tí- 
tulos. ya que pois exceder el espacio 
para ponerlos (esto puede arreglarse 
cambiando el scale del objeto text). 


ALA 
Ñ ns 


Biblioteca 3D 


Modelos para una batalla : 


Durante meses los rendermaníacos han enviado material bélico para 
participar en la batalla entre Orcos y Humanos que estaba prevista para 


este mes. Catapultas, cañones, transportes, e incluso un 


par de guerreros y un mago han llegado a Rendermanía 
para apoyar a uno u otro bando. Y este mes (¡por fin!) ha 
llegado la hora del encontronazo virtual. Sin embargo, la 


horda orca no se ha presentado. En su lugar ha acudido 


al campo de batalla una horda de no-muertos. 


nte todo. quisiéra- . 
mos disculparnos . 
por haber sustituido : 
a la horda orca por E 
los zombis que po- : 
déis veren estas pá- ¿ 
ginas. Esto ha sido debido a una imper- a 
donable falta de previsión. En el z 
número anterior nos pareció que ya ha- ; 
bía material suficiente para preparar : 
una buena batallita virtual, pero faltaba : 


lo más importante: ¡los Orcos! 


Por qué no hay orcos 


Lo cierto es que, como recordarán : 
los lectores, disponíamos de un orco : 
que había sido cedido amablemente por ¿ 
José González Iniesta. Este orco era un . 
magnífico representante de la raza ver- : 
de: tenía grandes colmillos, unos hom- S 
bros de metro y medio de ancho, una a 


apariencia : 
que inspiraba ¿ 
terror al enemigo y. cómo no, despren- : 
día un hedor capaz de poner en fuga a E 
cualquier humano. Sin embargo, al fi- . 
nal no pudo ser utilizado. ¿Por qué? E 
Pues porque el orco no había sido dise- E 
ñado expresamente para una batallita : 
virtual como la que se pretendía prepa- : 
rar. No estaba articulado y Únicamente a 
poseía una textura para la parte frontal. . 

Como el modelo no estaba dividido 
en dos partes, la textura —creada para . 
representar la parte delantera del orco— z 
quedaba aplicada también en la parte a 


de fantasia medieval 


posterior de la criatura verde. con lo 
cual no resultaba conveniente que el 
modelo quedara de espaldas a la cáma- 
ra (¡entonces se apreciaba que no había 
espaldas, sino dos lados delanteros!). 
Así, el orco solamente podía ser visto 
de frente (bastaba con hacerlo girar 
unos pocos grados para advertir que es- 
taba incompleto). Quizá se pudo haber 
creado una escena donde los orcos sólo 
presentasen la parte frontal a la cámara, 
pero esto hubiese recortado seriamente 
las posibilidades en el diseño de la por- 
tada. Además, los guerreros humanos 
estaban articulados y podía prepararse 
cualquier número de posturas para 
ellos; por tanto resultaba deseable ha- 
cer lo propio con los orcos. 

De esta manera se llegó a la conclu- 
sión de que se necesitaba un orco tan 
manejable como el lancero humano. 
Fue entonces cuando, sabiendo que Jo- 
sé González tenía en ese momento tra- 
bajo suficiente como para ahogarse en 
él, decidimos hacer nosotros mismos 
al orco. 

Para ello disponía de la magnífica 
documentación que supone la revista 
White Dwarf, donde hay docenas de 
fotografías de miniaturas de orcos. 
Pronto, no obstante, hubo que rendirse 
a la evidencia: preparar un orco míni- 
mamente aceptable no es algo que se 
haga en unas pocas horas. Quien haya 
visto alguna de las muchas ¿lustracio- 
nes que existen sobre esta raza fantásti- 
ca sabrá que los orcos no suelen llevar 
armaduras. La mayor parte de su cuer- 
po —parecido al humano pero mucho 


más fornido— queda al descubierto. Era 
pues preciso crear un cuerpo antropo- 
mórfico que exhibiera lo más fielmente 
posible la brutal musculatura orca. Ha- 
cer esto desde cero ya suponía una ta- 
rea muy difícil pero, además, también 
era preciso crear un rostro que pudiese 
variar de expresión y que fuese fácil- 
mente deformable, lo cual era —como 
ya imaginará el lector— una empresa 
aún más laboriosa. Resumiendo, las al- 
ternativas posibles eran: 


1) Crearlo todo (cuerpo y cabeza) 
partiendo de cero. 

2) Realizar deformaciones de una 
malla freeware de un cuerpo humano 
hasta obtener el orco. 

3) Utilizar bitmaps para represen- 
tar detalles inexistente en un modelo 
3D básicamente muy sencillo (como es 


el caso de los modelos de «Quake» o 
del propio orco de José González). 

4) Crear un modelo muy simple 
que solamente fuese visto a distancia. 

5) Hacer otra cosa. 

6) Renunciar a la batallita. 


Las dos primeras opciones se pusie- 
ron en práctica hasta que resultó evi- 
dente que los progresos eran demasia- 
do lentos. ¡Sencillamente no había 
tiempo de hacer un orco decente en los 
días disponibles! En cuanto a la tercera 
opción, nuestra habilidad como grafis- 
tas 2D no estaba a la altura de las cir- 
cunstancias. La siguiente opción, la 
cuarta, fue rechazada sin más, puesto 
que se deseaba un orco del que sus co- 
legas verdes no se avergonzaran. Así 
pues, sólo quedaban dos opciones: o 
bien renunciar al encuentro o bien “ha- 
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cer otra cosa”. Por supuesto también se 
hubiera podido aplazar el encuentro pe- 
ro esto hubiera sido defraudar a todos 
aquellos que deseaban participar en él. 
La batalla, pues, debía celebrarse a to- 
da costa, aunque faltaba uno de los 
bandos... 


La noche de los muertos 
vivientes 

Afortunadamente somos auténticos 
devoradores de literatura fantástico-he- 
róica y por esta razón no tuvimos que 
estrujarnos los sesos hasta niveles críti- 
cos para hallar una solución. Los adep- 
tos al género, quienes hayan leído a 
Howard, Zelazny, Leiber, Moorcok, 
Tolkien y a tantos otros, se habrán dado 
cuenta de que tarde o temprano en estas 
historias siempre aparece una legión de 
muertos vivientes (de hecho, en «War- 
hammer» también figura un ejército de 
no muertos). Esta fue la solución adop- 
tada por razones obvias. En primer lu- 
gar diseñar un zombi es muy fácil, úni- 
camente hay que hacerse con algún 


modelo de esqueleto y modificarlo para 
nuestros fines. Además el no-muerto, 
al consistir solamente en huesos, no 
presenta las complicaciones de mode- 
lado típicas de las caras o de los mús- 
culos y resulta muy fácil articularlo (to- 
do el mundo sabe dónde están los ejes 
de giro de un cuerpo humano). 

Una vez tomada esta resolución el 
siguiente paso a tomar fue considerar 
dónde iba a tratarse el modelo. O sea, 
dónde iban a crearse las diferentes pos- 
turas que, más tar- 
de. en «POV», se 
emplearían para 
generar las esce- 
nas. Esta decisión 
no fue difícil. 

«Imagine» dis- 
pone de un exce- 
lente modelador 
que resultaba ade- 
cuado para crear 
los pocos objetos 
necesarios. Permi- 
te una fácil modi- 


ficación de los modelos utilizando ope- 


raciones que pueden afectar a objetos, 


caras o puntos y, sobre todo, es ideal 
para establecer jerarquías de objetos, lo 
cual es indispensable para preparar 
posturas. 


El guerrero humano 

Una vez decidido el uso de «Imagine» 
se optó por preparar al guerrero huma- 
no en primer lugar. Este era el modelo 
que iba a representar al bando humano. 
Fue creado en «3D Studio» y era dese- 
able comprobar si iban a presentarse 
problemas de traducción de formatos 
antes de empezar con el esqueleto (que 
también es un modelo de «3D Stu- 
dio»). Efectivamente hubo problemas. 

Para empezar se suponía que tanto 
«Imagine» como «3D Studio» pueden 
leer ficheros dxf. Pues bien, mientras 
que «3D Studio» no presentó proble- 
mas para leer los dxf grabados desde 
«Imagine», este último si los dio para 
leer los dxf grabados desde «3D Stu- 
dio». «Imagine» se ponía a leer y a leer 
para, finalmente, mostrar un eje solita- 
rio en pantalla, pero del objeto leído, ni 
rastro. Por supuesto, uno siempre tiene 
que dejar una puerta abierta a la admi- 


sión de haber cometido un 
error o alguna omisión ca- 
tastrófica, pero en este ca- 
so, al no haber encontra- 
do opciones de lectura, 
simplemente se aceptó 
que esta opción no fun- 
cionaba (probablemente lo 
hará con archivos dxf más 
antiguos que los que graba 
«3D Studio»). Entonces se 
empleó el conversor Wevt2pov, ya pu- 
blicado hace tiempo en PCmanía. 
Wevt2pov no realiza traducciones di- 
rectas al formato de «Imagine» pero 
permite leer ficheros 3ds y grabar dxf. 
Después de las primeras pruebas se 
comprobaron dos cosas: 


A) «Imagine» leía los dxf grabados 
por Wevt2pov (aunque tardaba un 
tiempo considerable en leer los más 
largos) pero convertía los modelos leí- 
dos en un único objeto. 

B) En caso de que se grabase pieza 
a pieza como dxf un modelo desde 
Wevt2pov, «Imagine» daba a los obje- 
tos leídos tamaños que no correspondían 
a sus dimensiones originales. Las pie- 
zas, por tanto ya no encajaban entre sí y 
se hacía preciso reescalarlas y posicio- 
narlas nuevamente desde «Imagine». 


Así pues, al no encontrar un conver- 
sor directo 3ds-obj, fuimos importan- 
do pieza a pieza desde «Imagine». Para 
reescalar y situar las piezas se importó 
también un modelo completo del lan- 
cero que sirvió de pista para compro- 
bar las dimensiones y la posición de ca- 
da objeto. Después de un trabajo 
mecánico y aburrido, el lancero quedó 
listo. Fue entonces y sólo entonces 
cuando, examinando las cartas del foro 


del lector encontramos la referencia a 
3dto3d en la carta de Víctor Tovío 
Ciércoles. (Nota del autor: estamos se- 
guros de haber oído antes referencias a 
3dto3d pero las habíamos olvidado to- 
talmente. Gracias, amigo Víctor). 


3dto3d 


3dto3d es un conversor de formatos 
3d. Permite una perfecta comunicación 
entre «POV», «3D Studio» e «Imagi- 
ne», aunque no pueden pasarse escenas 
de «POV» a «3D Studio» ni a «Imagi- 
ne». Las traducciones realizadas con 


3dto3d presentan algunos 
problemillas menores pe- 
ro la alternativa —como 
habréis comprobado por 
los párrafos anteriores— 
es mucho peor. 

La versión que este mes 
publicamos es la remitida 
por Víctor. Esta versión 
ya había sido publicada 
antes en la revista, pero 
no lo recordamos a tiempo. La versión 
funciona bajo MS-DOS por el sistema 
de la línea de comandos. El formato de 
uso de la utilidad es: 


3dto3d fichero.ext /opción /opción 


Hemos de indicar a 3dto3d el forma- 
to del fichero a traducir con la opción 
“1”. A este carácter seguirá un valor in- 
dicando el formato del fichero de en- 
trada. Un valor de O (el asignado por 
defecto) corresponde al formato Raw. 
El valor 1 es el de los ficheros 3ds («3D 


A 


Studio»), el 2 el de los archivos .obj E 
(«Imagine») y el 3 el de los ficheros E 
Lwo («Lightwave»). Para especificar el ¿ 


formato del fichero de salida usaremos : 
la opción “o” seguida de un valor nu- , 
mérico. Este valor será de O para los fi- E 
cheros raw puros (sin almacenar los ¿ 
vectores de las normales), de 1 para los a 
raw suavizados (en los que sí se alma- a 
cenan estas normales), y de 2 para a 
«POV». Merece la pena indicar que la j 
opción 2 graba también un fichero en S 
formato Udo que -según parece— pue- : 


de ser leído por «Moray». 


Otros valores válidos para “o” son el . 
3 («Polyray»), el 4 (Asc, el formato as- A 
cii de «3D Studio»), el 5 (Obt), el 6 ¿ 
(Rpl de «Real 3D»), el 7 (3ds), el 10 ¿ 
(obj de «fmagine»), el 11 (Rwx de E 
«Renderware»), el 12 (Wrl de «Vrml S 
1.0») y el 13 (Dxf). Los valores 8 y 9 se : 
emplean respectivamente para generar E 
objetos wireframe y blob para «POV», a 


pero no han sido probados aún. 
Así pues, por ejemplo, la línea... 
3dto3d nombre.3ds /11 /o10 


...generaría un fichero obj para , 
«Imagine» a partir del fichero de «3D . 
Studio» dado como entrada. Esta con- E 
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versión no parece presentar problemas 
pero lo contrario sí puede ocasionar al- 
gunos contratiempos. Á veces, los mo- 
delos obj exportados al formato de «3D 


Studio» no se visualizan correctamente : 
desde «3D Studiv» y puede suceder 


que la mitad de los polígonos no sean 
visibles. Si queremos solucionar esto 
desde el mismo «3D Studio» bastará 
con unificar las normales del objeto. 
¡Los polígonos están ahí! únicamente 


ocurre que el lado visible de las caras ¿ 


(indicado por la normal de cada polí- 


gono) apunta en dirección opuesta a la ¿ 


visible. También podemos añadir la op- 
ción /u a la línea de órdenes de 3dto3d. 


Esta orden —según el manual— unifica ¿ 


las normales del objeto, pero aparente- 
mente no funciona. También puede su- 
ceder que el modelo se vea facetado 
desde «3D Studio» aunque original- 
mente su superficie estuviese suaviza- 
da. Para remediar esto desde «3D 
Studio» 


bastará con aplicar un comando de sua- 
vizado (nota: 3dto3d también ofrece el 
comando /s para hacer esto pero, nue- 
vamente, parece no tener efecto). 

Por el contrario la conversión 3ds - 
obj no dio problemas en ninguna de las 
pruebas realizadas y fue así cumo el 
modelo del esqueleto se pasó a «Imagi- 
ne». Después de la conversión. los ob- 


¿ jetos componente del modelo siguen 


siendo independientes en «Imagine». 
No se fusionan en un único objeto. To- 
dos los objetos individuales se atarán a 
uno de mayor jerarquía (que, es de su- 
poner, 3dto3d elegirá “a dedo”), y todo 
el modelo podrá ser referenciado pin- 
chando sobre este objeto “padre”. Una 
vez que tenemos el modelo en la panta- 
lla de «Imagine» podremos desagrupar- 
lo y establecer las jerarquías necesarias 
antes de grabarlo. 


Preparación de los 
luchadores 

Una vez cargados los dos modelos 
en el Editor de Detalles de «Imagine», 
se crearon las relaciones jerárquicas 
para poder preparar las posturas nece- 
sarias para 
la batalla. 
Antes, 
sin 


embargo, se estudió el tamaño relativo 
entre ambos modelos y se realizaron al- 
gunos ajustes de poca importancia en 
los dos. Quizá el más importante sea el 
realizado en las manos. Aunque crear 
posturas nuevas de modelos como es- 
tos puede ser bastante divertido, colo- 
car la posición de las manos es siem- 
pre una tarea molesta. Simplemente 
hay demasiados objetos y puntos de gi- 
ro. El usuario pierde siempre un buen 
rato colocando la posición de cada de- 
do y a menudo se encuentra con que la 
disposición obtenida no resulta ade- 
cuada y hay que volver a empezar. 
Para estos personajes se decidió su- 
primir el problema de raíz. En los dos, 
las manos están cerradas, como asien- 
do algo, y forman un único objeto ata- 
do a la muñeca. La idea surgió ojeando 
una White Dwarf. Al contemplar las 
fotografías, observamos que práctica- 
mente todas las miniaturas tenían las 
manos cerradas en un puño, lo cual era 
lo más natural del mundo ya que siem- 
pre asían algo: un escudo, una espada, 
una lanza... Incluso en los raros casos 
en que una mano quedaba libre, ésta 


humano fuera bastante más bajito. así 
que el zombi le saca más de una cabe- 
za. También se aumentó bastante el ta- 
maño de la cabeza y de las manos ori- 
ginales del esqueleto —a fin de que no 
resultase un modelo demasiado serio— 
y finalmente se le añadieron unos Ojos 
Nota: parece increíble cómo puede 
cambiar un esqueleto al ponerle ojos. 
Con las cuencas oculares vacías, el mo- 
delo da miedo mientras que con los 
ojos, el modelo pierde bastante horror 
y puede. en algunas posturas, hasta dar 


risa. Este efecto de caricatura puede au- 


nar las proporciones finales de los dos 
guerreros y sus armas. Originalmente 
el humano era un lancero y de hecho se 
preparó una lanza para él, pero final- 
mente no se preparó ninguna postura 
con ella. En lugar de esto se decidió 
preparar una espada de aspecto bastan- 
te bestial y un escudo. Esto se hizo en 
parte para dar un aspecto más combati- 
vo al personaje y en parte porque resul- 
taba mucho más sencillo preparar pos- 
turas para él poniéndole un objeto en 
cada mano que haciéndole asir una lan- 
za con las dos manos (probadlo y ve- 


formaba un puño. Esto deja abierta la 
posibilidad de que el personaje agarre 
el mismo arma con las dos manos (co- 
mo se ha hecho en un par de posturas 


del zombi) o de que se pueda colocar 


e 


otro arma fácilmente. Una vez decidido 
esto se preparó la postura para la mano 
esquelética y se unió (Join) en un único 
objeto. La maño del humano fue algo 
más complicada ya que la que se pre= 
paró originalmente fue sustituida por 
Otra recortada de la malla de un modelo 
humano (borrando el resto de los pun- 
tos del modelo). 

Después se fijaron las proporciones 
de ambos modelos. Se deseaba que el 


amo 


mentar si quitamos algunos huesos y 
damos mayor tamaño a algunas articu- 
laciones como la cabeza, los pies, las 
manos, etc. En nuestro vaso. estos cani- 
bios sólo fueron moderados. 


Armas para la contienda 

El siguiente paso fue preparar las ar- 
mas para ambos contendientes. En el 
fichero base.obj, el lector podrá exami- 


réis). El diseño de estas armas no pre- 
sentará ningún misterio para los 
lectores que hayan leído las notas que 
hemos ido publicando sobre «Imagi- 
ne». El escudo son dos discos extrui- 
dos, uno de lus cuales fue recofjado. La 
hoja de la lanza se creó dibujando, una 
forma bidimensional que fue extruld::, 
editándose después sus puntos. Por úl- 
timo, la hoja de la espada se creó edi- 
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tando los puntos de un plano 
extruido (con práctica este 
método es más rápido de lo 
que parece a primera vista). 

Una vez creadas las ar- 
mas, estas fueron traslada- 
das y rotadas hasta colocar- 
las en los puños de nuestros 
audaces contendientes, des- 
pués de lo cual fueron “ata- 
das” a los objetos-mano co- 
mo objetos-hijos. 


La conversión a «POV» 

Como los modelos iban a ser rende- 
rizados desde «POV», era preciso que 
éstos se almacenaran en una posición y 
escala que facilitará su manejo desde 
este programa. Como ocurría con «3D 
Studio» y «POV», «Imagine» tie:> los 
ejes cambiados con respecto a nuestro 
trazador favorito, y fue preciso realizar 
unas cuantas operaciones sencillas para 
no hacer posteriores ajustes desde 
«POV». Hecho esto los modelos, una 
vez importados por «POV», quedaron 
con los pies sobre el suelo fo por 
el plano X-Z, a la altura Y=0. La cara 
de los modelos quedó mirando parale- 
lamente al eje Z, en dirección al lado 
negativo del eje. Veamos cómo conse- 
guir esto. Hay que seguir estos pasos: 


1) Hay que rotar el modelo hasta 
que éste quede como puede verse en la 
foto: de pie y mirando hacia el especta- 
dor en la ventana Top, de modo que pa- 
rezca visto desde arriba —y con los pies 
apuntando hacia el marco inferior de la 
ventana— desde arriba en la ventana 
Front. También deberá quedar extendi- 
do horizontalmente, con la cabeza ha- 
cia el lado derecho y mirando hacia 
abajo, en la ventana Right. 


12 Rendermanía 


Biblioteca 3D 


2) Después hay que situar los pies 
del personaje sobre el que será el suelo 
en «POV». Para ello iremos al menú 
“Display” y pulsaremos sobre la op- 
ción “Coordinates”. Entonces aparece- 
rán sobre la fila superior tres valores 
numéricos que irán variando conforme 
desplacemos el cursor. Estos valores 
corresponderán a la posiciones X.Y,Z 
sobre las que vaya pasando el cursor, 
al desplazarse por las ventanas de tra- 
bajo. Elegiremos una vista, colocare- 
mos el cursor en la mismísima suela 
del zapato del personaje y tomaremos 
nota del valor devuelto en el eje Y (el 
valor del centro). Hecho esto sólo nos 
restará efectuar una traslación del mo- 
delo. Podemos hacerla manualmente 
pero resulta más preciso recurrir ala 
ventana de transformaciones (Alt-T). 
Escribiremos en la columna del eje Y 
el valor leído antes, pero dándole el 
signo opuesto (y no olvidéis el Re- 
turn). Además deberemos pulsar sobre 
el flag de “World” antes de pinchar so- 
bre “Perform”. 

3) Finalmente escogeremos un 
punto del personaje como centro en el 
plano X-Z. Lo ideal es hacer esto des- 
de la ventana donde vemos al persona- 
je desde arriba. Como antes, tomare- 
mos nota de los valores devueltos por 
el cursor para este punto central (pero 


ahora para X y Z). Luego in- 
vocaremos nuevamente al 
gestor de transformaciones 
para el modelo y daremos los 
valores leídos (que son, claro 
está, la distancia a <0,0> de 
los ejes X y Z) cambiando el 
signo. Así, después de pin- 
char en “World” y “Perform”, 
el muñeco estará perfecta- 
mente centrado en la posición 
desde la que debe ser “traducido” a 
«POV» 


Una vez obtenidas la orientación y 
la posición con que el personaje apa- 
recería en «POV» después de la tra- 
ducción, llegó el momento de ponerse 
a preparar posturitas. Para nuestra ba- 
talla se necesitaban muchas posturas 
diferentes de humanos y zombis dando 
y recibiendo leña. Cada postura impli- 
caba un fichero que sería traducido al 
formato de «POV» más tarde. Como 
las posturas se crearon partiendo de la 
orientación y posición ya logradas en 
el primer modelo grabado, todos los 
modelos-postura aparecieron en el uni- 
verso de «POV» con los pies sobre la 
posición <0,0,0>. Esto ya garantizaba 
que noiba a costar mucho ir situándo- 
los en el campo de batalla. Después de 
Mevar a cabo los tres pasos ya descritos 
se grabó el modelo y se realizaron en 
él-los cambios necesarios para cada 
postura. Cada vez que se obtenía una 
nueva postura, se.la grababa y se rese- 
teaba al Editor de Detalles para leer de 
nuevo la postura original sobre la que 
se deseaba trabajar para obtener todas 
las demás. Por supuesto, también se 
podía emplear alguna de las posturas 
ya obtenidas, cuando ello resultaba 
más fácil. 


y 


Otra vez el 3dto3d 

Supongamos que ya tenemos todos 
los ficheros-postura. Procederemos a 
convertir cada obj con una línea como... 


3dto3d postura.obj /12 /02 /s45 


Esto creará un fichero inc que será 
directamente digerible por «POV». 
Hay, sin embargo, un problema. La 
conversión a «POV» creará un declare 
para cada objeto dentro de un fichero 
Inc que puede tener varios Megas de 
tamaño. No se crea, sin embargo, nin- 
gún Adeclare para la unjón de todos los 
objetos constituyentes del modelo. Y 
tampoco:se añaden texturas, ni pig- 
mentos, ni luces, ni cámaras. (Nota: 
nosotros no hemos hallado ninguna op- 
ción de 3dto3d para ello). 

Esto derivó en una terrible pesadilla 
pues obligó a emplear un Editor de 
Textos en cada uno de los 25 archivos- 
postura para colocar manualmente las 


texturas y eliminar los declares (el lec- 


tor podrá imaginarlo si tiene 
en cuenta que cada .inc 
obtenido tiene 
un tamaño que 
oscila entre los 
3.5 y los 4 Me- 
gas para cada 
modelo-postura). 
Desde los ficheros escénicos de 
«POV» cada postura se trata asf: 


object[+tinclude “posturaX.inc” rotate 
<x,y,z> translate <nx,ny,nz> ] 


Naturalmente la postura podría ha- 
berse grabado como un único objeto 
antes de realizar la traducción pero ello 
hubiera implicado que sólo habría un 
color por postura. Finalmente hay que 
recordar que 3dto3d graba también un 
fichero udo por cada postura. En nues- 
tro caso este fichero no nos interesa de- 
masiado, pero puede ser conveniente 
que toméis nota de que, al principio del 
mismo, se añaden las dimensiones del 


modelo convertido en los distintos ejes. 
Esto puede ser muy útil para estimar 
las distancias en la colocación de los 
modelos. 

Nota: 3dto3d solamente convierte fi- 
cheros .obj de «Imagine», no objetos 
creados desde el Editor de Formas. Pa- 
ra traducir objetos creados desde este 
módulo será preciso grabarlos desde el 
Editor de Detalles y darles la termina- 
ción .obj. 


Las posturas 

Para la batalla se prepararon 25 pos- 
turas del zombi y del humano. Hay 
golpes, caídas, cadáveres e incluso 
posturas de los personajes volando 
(tras recibir supuestamente un cañona- 
zo). Pero lo cierto es que hubieran sido 
necesarias muchas más para preparar 
una batallita en condiciones. Desafor- 
tunadamente cada postura, humana o 
zombi, demanda mucha memoria de 
«POV» (¡unos 8 Megas!). En estas cir- 
cunstancias, ¿para qué hacer más? Aquí 
se echó en falta una buena utilidad de 
reducción de polígonos, Con ella hu- 
biera sido sencillo reducir el tamaño de 
los archivos a dimensiones manejables. 

Podéis encontrar los ficheros obj con 
los modelos en el CD-ROM. 
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La Portada 


Trazado de batallas 


En portada podéis 
admirar diversos 
modelos realizados 
por los lectores como 
apoyo a la idea de un 


enfrentamiento virtual 


entre humanos y orcos. 


Esta idea inicial ha 
sufrido ciertas 
modificaciones 
debidas a limitaciones 
en el tiempo y en el 
hardware disponibles. 
Seguidamente 
estudiaremos estos 
problemas teniendo 
en mente futuras 
colaboraciones de los 
rendermaníacos en 


próximas portadas. 


dl 
2 
o 
o 


in duda, la portada : 
del presente número ¿ 
supondrá una sor- ¿ 


presa, y probable- 
¿en detalle todos los problemas que se 
ción. para todos 


mente una decep- 


aquellos que esperasen encontrar una 


1 


chando. Las razones de la no compare- 
cencia del bando orco ya han sido ex- 
plicadas, por lo que no vamos a insistir 
en ellas. En lugar de esto explicaremos 


dieron en la generación de esta escena, 


¿a fin de prevenir su repetición en próxi- 


imagen repleta de orcos y humanos lu- ¿ 


mas Ocasiones. 


-. 


Falta de memoria 

Las limitaciones antes mencionadas 
han determinado en gran medida las 
modificaciones hechas a la idea origi- 
nal. El problema más grave ha sido, por 
supuesto, el de la memoria: la portada 
había de generarse en un PC con 64 
Megas de RAM y cada personaje, hu- 
mano o zombi, precisaba de 8. Esto ha 
limitado enormemente el número pre- 
visto de contendientes y constituye un 
monumental fallo de planificación por 
nuestra parte, ya que los requerimien- 
tos de memoria del guerrero humano 
eran conocidos desde hacia tiempo. 
(Nota del autor: en mi descargo debo 
añadir que, aunque conocía el proble- 
ma podía hacer bien poco por reme- 
diarlo puesto que no dispongo de nin- 
gún reductor de polígonos. Además 
resulta bastante difícil crear buenos 
modelos con cientos —en vez de miles— 
de caras, En estos casos suele ser preci- 
so realizar bitmaps para disimular la 
falta de detalle de estos modelos y, co- 
mo ya hemos comentado antes, no so- 
mos especialmente hábiles como gra- 
fista 2D). 


Los modelos de los 
rendermaníacos 

Para la portada hemos seleccionado 
las máquinas de guerra enviadas por 
Óscar Álvarez Díaz, Daniel Susín Ace- 
bo. Julián Hierro García y Carlos Vilas 
Arias. También estaba previsto incluir 
el maravilloso mago de Juan Carlos Ji- 
ménez Méndez. pero al final no fue in- 
cluido debido a la falta de RAM (esta- 
ba previsto darle el mando del ejército 
zombi pero al final, en vista del escaso 
número de no-muertos que compare- 
cieron...). También hubo otros modelos 
que, por una y otra razón, no pudieron 


ser incluidos en es- 
ta lista. Entre ellos 
podemos citar a 
Roberto Reboiro 
Jato. Su catapulta 
merecía ser inclui- 
da aquí pero, desa- 
fortunadamente, 
Roberto sólo envió 
los mdl. Nosotros 
no teníamos insta- 
lado «Moray» y. 
debido a la falta de 
tiempo, no fue po- 
sible efectuar la 
conversión. 

Por otro lado la 
preparación de los 
modelos incluidos 
se llevó su tiempo. 
Lógicamente. al 
no haberse publicado instrucciones so- 
bre este particular, cada lector envió su 
trabajo con una escala y orientación de 
ejes distinta. Esto obligó a leer los 
fuentes y a realizar ligeros cambios pa- 
ra adaptar los modelos a la escala y 
orientación pensados para la portada. 
Esta tarea fue bastante fastidiosa ya 
que nadie pensó en poner comentarios 
en sus fuentes indicando las dimensio- 
nes de sus modelos y la altura a la que 
se había colocado el suelo. Además, 
casi ningún lector pensó en centrar los 
modelos en los ejes. lo cual hubiera fa- 
cilitado mucho la tarea de situarlos en 
la escena. 

Otro detalle fastidioso en que caye- 
ron bastantes lectores fue el de renom- 
brar las declaraciones de bastantes tex- 
turas de madera o metal. Como el 
fichero de generación de la portada in- 
cluía varias Catapultas que empleaban 
las mismas texturas de madera, esto 


ocasionó que se produjeran cambios 
en el acabado de otros modelos que 
empleaban las mismas texturas y tam- 
bién aparecieron algunos bugs que re- 
quirieron un fastidioso proceso de de- 
puración. Finalmente. algún lector ha 
incluido modelos cuyos fuentes de- 
mandaban algún bitmap que no ha sido 
proporcionado. 


La portada final 

La idea inicial para la portada con- 
templaba el uso de las viejas librerías 
de pueblos y castillos medievales que 
se publicaron en los primeros números 
del suplemento Rendermanía. Sin em- 
bargo, había varios factores que desa- 
consejaban el uso de estas librerías pa- 
ra construir los fondos de la portada. El 
problema principal venía dado por los 
requerimientos de memoria. La razón 
de este excesivo gasto radica en que las 
dos librerías están agrupadas en dos 
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grandes ficheros que em- 
plean un gran número de 
declaraciones (para una 
próxima versión esto 
cambiará y la librería se 
descompondrá en un buen 
número de ficheros inc 
más pequeños). Por otro 
lado, además, no deseába- 
mos emplear nuevamente 
estas librerías en una por- 
tada en tanto no se inclu- 
yeran mejoras como nuevos edificios, 
nuevas texturas, etc. 


Entonces, después de quemar neuro- 


nas durante algún tiempo, apareció 
siguiente idea: ¿por qué no emplear a 
odelos 
como qa fuesen miniaturas que estuvie- 


los guerreros y al resto de los n 


crear esta o. únicame 
delos soN e 
mesa y colocar también los objet: 
picos que pueden ver: 
lápices, teclados de or 


necesario situar los 


etc. Por supuesto de 
de los objetos-libros 
sólo había un paso. 


buen contraste. 
El siguiente paso, una vez co ocadas 
las filas de libros, fue decidir la orienta- 


ción de la cámara. Como no se E 
perder más tiempo añadiendo detalles 


adicionales como paredes, muebles, 

etc., se enfocó la cámara de modo que 
las filas de libros actuasen como fondo. 
Al mismo tiempo, como se precisaba 
enfocar un buen trozo de mesa donde 
colocar las miniaturas, la cámara se dis- 
puso de tal manera que pudiese captar 
tres zonas diferenciadas: la librería de 


A 


La Portada 


(de s ii 


E mesa): También hubiera qu 


tener las miniaturas, pero no se dispo- 
ía del tiempo suficiente para crear es- 


Aj nde pets o se hayan 

Sí cambios hechos ala 

ru original Mato s remedio!) 

Si algún día la balla puede celebrarse, 
estos modelos serán utilizados. 

Ahora veamos las cláusulas que re- 
girán la creación de las próximas por- 
tadas hechas con ayuda de los lectores: 

1) Cada 4 meses se publicará una 


Ita ener los modelos y también a su orien- 
ES py al programa en que se realiza- 


portada que incorporará 
modelos hechos por los 
lectores. El motivo de la 
portada deberá ceñirse 
—aunque sea tangencial- 
mente como en el presen- 
te caso— a un tema anun- 
ciado previamente. Si la 
respuesta de los lectores 
es insuficiente, la portada 
se cancelará. 

2) Para cada portada se 
publicarán reglas especiales adiciona- 
les, según sea el caso. Estas reglas se re- 
erirán a las dimensiones que deberán 


con los pies a la 
efe rentemente mi- 
-2). 


será “Mechs”. Si utilizáis 
o «Imagine» se agradecerá 


y: que e table zcáis las jerarquías de obje- 


si lo preferís, podéis enviar 


a o 
as t tamos en que los autore las “posturas” que creáis adecuadas. En 


caso de que se reciba un número de mo- 
delos muy alto, serán empleados los que 
se consideren mejores o más apropiados 
para el motivo de la portada. Nota: esta 
portada no tiene por qué ser una escena 
de guerra. También podéis enviar suge- 
rencias acerca de cómo imagináis voso- 
tros la portada o de cómo preferís que 
se empleen vuestros modelos en ella. 


A 


El Foro del Lector 


Nota importante. Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 
I 
figura en la segunda página de Penanía, o vía e-mail a rendermania.pcmania O hobbypress.es 


Babel Virtual 


Hoy nuestro foro es un verdadero Babel en cuanto a las técnicas y 
programas empleados por los autores. 3D Studio, Imagine, POV, Moray e 
incluso MAX han sido utilizados para crear los trabajos que podéis 
admirar hoy. Extraterrestres, soldados espaciales, máquinas medievales, 
Mechs... Las herramientas, los temas, las preferencias y las ideas son 


diferentes en cada caso pero hay algo que todos los rendermaníacos 


tienen en común: la pasión por la infografía. 


A Jose Antonio Siñuela Rajo y a su hijo Da- 
vid les gustó la original idea de Jorge Martín 
Cuervo, el cual publicó en el número 6 de Ren- 
dermanía una librería virtual de piezas del juego 
Tente. Por ello, José Antonio y David han reto- 
mado la idea y han creado una librería de piezas 
del juego K'nex. Las piezas, creadas con 3D Studio por José Antonio, fueron empleadas por David (de 12 años) para montar el helicóp- 
tero de juguete que padre e hijo nos han enviado como ejemplo. Aquí se me ocurre una pequeña idea: alguien podría diseñar un juego de 
construcción partiendo de cero y enviar modelos construidos con él. ¿Quién sabe? Quizá, si la idea está bien pensada, Su autor podría re- 
gistrarla. Y aquí, si laidea atrae a un número lo suficientemente alto de lectores, podríamos dedicar una portada al tema “Juegos de Cons- 
trucción”. Os felicito por vuestro trabajo. 
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El Foro del Lector 


Roberto Celorrio del Pino nos envía un modelo basado en los marines es- 
paciales del capítulo de los ángeles Sangrientos, del juego Warhammer 
40000. Este fantástico modelo está, como podéis ver por las 
fotos, totalmente articulado. y Roberto nos adjunta 
no sólo la malla correspondiente, sino también las 
texturas. En su carta, Roberto hace una autocrítica 
bastante dura, ya que el modelo no es exactamente igual a la 
miniatura en que está basado, pero en mi opinión el único defecto re- 
señable está —como también señala el propio autor—en la hombrera, ya 
que ésta secciona el antebrazo. El modelo ha sido creado con 3D Studio ha- 
ciendo uso del comando Fit y aplicando operaciones Csg y de deformación. 
Roberto ha declarado su modelo como de libre uso y tan sólo pide que se 
mencione su nombre. ¡Enhorabuena por tu magnífico trabajo! Espero ver lu- 
char algun día a tu infante en algún ¡Waaagh! o en alguna invasión Geneleaster. 


Ángel Ruiz Guijarro 

nos ha enviado su 

primer trabajo con 

Imagine. Se trata de 

un modelo femenino 

creado para hacer 

compañía a Ray y 

defenderle de los 

abusos del grandu- 

llón que apareció en 

el número 5 de Ren- 

dermanía. Pues bien. 

amigo Ángel, siento 

desilusionarte, pero 

Ray ya está enamo- 

rado desde hace 

tiempo. Su corazón 

virtual suspira por los 

huesos de una de las 

chicas de Tomwoof. 

Ella, sin embargo, le ha dado calabazas hasta ahora adu- 
ciendo que no es más que un muñeco de madera. En fin.... 
En cuanto a lo que dices sobre los pechos, podrías 
emplear la edición de puntos, el magnetismo o el Editor 
de Formas o una mezcla de técnicas. No existen reglas 
fijas para el infografista. Cada uno modela empleando 
las herramientas que prefiere. De todas formas te hago 
notar que unos pechos “más reales” desentonarían en tu 
muñeco (yo se los quitaría y le pondría mejor un lanza- 
cohetes). En cuanto al traspaso de los modelos desde 
Imagine a POV, el único conversor que conozco que tra- 
ta los ficheros .obj es 3dto03d de Thomas Baier, que se 
incluye en este número. Ah, en cuanto a lo de trastear en 
tu modelo, yo prefiero casi siempre empezar desde cero. 
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Benjamin Albares Moreno regresa 
a estas páginas para enviar algunas 
imágenes que representan un gran 
avance con respecto a sus anteriores 
trabajos. Benyi nos e.vía una extensa 
carta en la que comenta el proceso de 
desarrollo de sus escenas y en la que 
pide unos comentarios. Pues bien, 
tus escenas me han parecido magníficas pero... ¿por qué tie- 
nen tan poco color? El efecto general es un poco frío. Quizá 
habría sido conveniente dar un color distinto a la cabeza del 
primer plano de Futuras, para que resaltara más sobre el fon- 
do, o bien cambiar el color de este. Por otro lado, estoy de 
acuerdo contigo en el papel que juegan las texturas metálicas 
en las robots, y me ha impresionado el estudio que has hecho 
para el Escorpión y el modelo en sí, aunque creo que hubiera 
quedado mejor como escorpión que como nave espacial. 
¡Hubiera dado mucho más asco! También habrías debido po- 
ner un fondo menos pobre en la escena del escorpión (a fin de 
cuentas echaste mucho esfuerzo en el modelo, ¿Por qué no 
entonces algo más de trabajo para presentarlo?). En fin, como 
modelador has mejorado un montón y estoy deseando ver 
acabada a la chica que estás preparando con Metaballs, 


nos ha enviado las que quizá serán sus últimas imágenes 
con 3D Studio, ya que piensa pasarse a MAX. Debido a un desastre en su disco du- 
ro, Alberto no ha enviado todos los ficheros de generación pero su carta (que debe- 
ría haber enviado también como fichero) me ha convencido de la autoría de las imá- 
genes. Alberto me ha pedido una pequeña crítica así que ahí va: tu punto fuerte 
parece ser la 
ambientación de las escenas más que el modelado en sí (contraria- 
mente a como sucede con la mayoría de los rendermaníacos). Pan- 
demonium2, por ejemplo, resulta asombrosamente tétrica, a pesar 
de la excesiva sencillez del templo (y de la textura que le has pues- 
to). Algo parecido ocurre con las demás escenas: en Alien, el mo- 
delo (hecho con metaballs) no parece demasiado resultón en sí mis- 
mo. pero en el contexto de la imagen transmite una sensación de 
peligro (por cierto, creo que acertaste al no ponerle ojos). También 
me ha gustado la escena del Androide. En resumen: creo que si po- 
tencias la complejidad de tus modelos conseguirás unas escenas 
espléndidas. Todo lo demás: la composición, las ideas, la atmoste- 
ra, etc.. me ha gustado bastante. 


ha decidido 
apoyar al bando humano con varias 
catapultas hechas con Moray y POV. 
En principio su plan consistía en en- 
viar un mago-enano, pero al final se 
decidió por los lanza-pedruscos. de 
los cuales uno es más bien un trans- 
porte de munición que una máquina 
de puerra. ¡Gracias por tu apoyo. 
Carlos! Y la próxima vez no emple- 
es tanta niebla en la escena. 


ha enviado una esce- 
na donde puede verse 
un modelo tiel del 
fantástico Marauder. 
cuyo diseño sirvió de 
base para el Mech 
que  incluí como 
ejemplo en el número 
7 de Rendermanía. 
Tengo que confesar 
que tu Mech me pare- 
ce mucho más atractivo que el mío, aunque espero superarme próximamente si se llega 
a celebrar una batalla entre Mechs en alguna de las próximas portadas. 

Sin embargo. tengo que decir que uno de tus discos llegó defectuoso. ¿Contenía las 
mallas de este modelo? 
En ese caso espero que 
me las envíes de nuevo 
junto con alguna nota 
indicando algo sobre el 
proceso de creación. En 
cuanto a tu pregunta so- 
bre cómo enviarnos 
animaciones, supongo 
que lo ideal sería hacer- 
lo en un CD, ya que to- 
do el mundo tiene uno 
(yo por ejemplo no dis- 
pongo aún de ningún 
removible). 


El Foro del Lector 


Roberto de los Ojos 
Gracia nos envía sus pri- 
meras escenas con POV. 
En su carta Roberto nos 
cuenta cómo ha pagado su 
condición de Povnovato. 
La verdad es que me reí 
bastante con lo que men- 
cionas sobre las ventanas 
del rascacielos (Roberto 
las puso todas a mano y 
solo después se enteró de 
la existencia de la senten- 
cia While). En fin, a mí me 
ha ocurrido algo parecido 
=si no peor- con mis mo- 
delos y 3dto3d. En cuanto 
a While, me parece que 
aún no has acabado de pi- 
llarle el tranquilo a 
las sentencias de 
programación, ya 
que dices que no su- 
piste utilizar esta 
sentencia con las 
ventanas de la esce- 
na de la residencia. 
Por otro lado tus 
imágenes me han pa- 
recido magníficas 
para ser las primeras 
y espero ver pronto 
las siguientes. 


Francisco 
Palao Reinés 
es un nuevo 


aficionado a la 


infografía que 

nos envía sus 

primeros traba- 

jos con MAX. 

Se trata de dos nuevas máquinas de guerra dise- 
ñadas para participar en la batalla virtual. El pro- 
blema es que no se aún nada de MAX y no pude, 
por tanto, editar los modelos para incorporarlos 
a la batalla (además, no conozco ningún traduc- 
tor para MAX). Sorry. En cuanto a la crítica so- 
licitada, creo que aún puede mejorar mucho en 
todo lo relativo al modelado aunque. como no 
conozco MAX. no puedo dar demasiados deta- 
lles útiles. Sorry otra vez. 


Roberto 97 


Tengo que agradecer a Víctor Povío Ciércoles el envío de 3dto3d. Lo 
cierto es que hasta ahora me había pasado inadvertida esta estupenda 
herramienta de conversión de formatos. En cuanto hice las primeras prue- 
bas con él lamenté no haber 
tenido antes este programa. 
¡La de trabajo inútil que me 
hubiera ahorrado sólo en este 
número! Víctor nos envía hoy sus primeros trabajos: un par de escenas y una anima- 
ción de un Mech modelado con Imagine y exportado a POV. Víctor ha incluido en su 
carta una descripción completa del proceso de traducción del modelo a POV (lo cual 
fue lo primero que llamó mi atención). Tanto las escenas como la animación se han 
renderizado desde POV y Víctor solicita otra de esas “c=íticas constructivas” que ha- 
cen que tanta gente no duerma bien por las noches. Pues bien, básicamente lo que 
puedo decirte es que aún puedes mejorar mucho en el apartado de modelado. Dedica 
por ahora más tiempo a esto antes que a otras cosas como la ambientación o la ani- 
mación. Gracias de nuevo por el 3dto3d, Espero tus próximos trabajos, 


